개요

앰비언트 모드에서는 무조건 Gateway API가 강제된다.
이에 더불어 설정을 하는 방법에 조금 차이가 있는데, 이걸 구체적으로 파본다.

E-앰비언트 모드 헬름 세팅에서 기본 세팅을 진행했다.

세팅

L4 레벨에서 인가 정책을 설정하고, 그 다음 L7의 트래픽 제어와 인가 정책까지 설정하는 식으로 진행한다.
웨이포인트가 있고 없고의 차이를 보기 위해 일단 웨이포인트 라벨을 없앴다.

kubectl label ns default istio.io/use-waypoint-

그리고 reviews 서비스로 들어가는 다음의 요청들을 만들었다.
참고로 미리 test 네임스페이스를 만들고 debug 파드를 만들어두자.

ADDRESS="reviews.default:9080/reviews/1"
#  ADDRESS="details.default:9080/details/1"
execute_test() {
  keti debug -- curl $ADDRESS
  printf "\n---------\n"
  curl http://$GWLB/api/v1/products/1/reviews -s
  printf "\n---------\n"
  keti -n test debug -- curl $ADDRESS
}
execute_test

debug에서 날리는 요청들은 헤더 내용들을 쉽게 커스텀할 수 있게 하기 위한 요청이다.
일반 curl은 productpage가 요청을 날리게 하기 위해 넣었다.
마지막으로 다른 네임스페이스에서 요청을 날릴 수 있는지도 확인한다.

요코로롬 기본적으로는 모든 응답이 성공한다.

Peer Authentication - mtls 제한

일단 첫번째로 test 네임스페이스의 debug가 요청하는 걸 보니 배알이 꼴린다!
이건 인가 정책에서 ALLOW 제한을 걸어서 막을 수도 있다.
그러나 ALLOW는 잘못 설정하는 순간 웬만한 모든 다른 요청을 막아버리기 때문에 사용에 주의할 필요가 있다.

생각해보면 어차피 test 네임스페이스에는 앰비언트가 적용돼있지 않은 관계로 요청은 정말 순수하게 평문으로 날아간다.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
 name: strict
spec:
  mtls:
    mode: STRICT
  selector:
    matchLabels:
      app: reviews

그렇기 때문에 Istio PeerAuthentication를 STRICT로 설정하는 것만으로 해당 요청을 막아버릴 수 있다.

해당 설정을 적용하면 ztunnel 로그에 관련한 설정이 적용됐다는 내용이 나온다.

그리고 이 내용은 istioctl을 통해서도 확인할 수 있다.

해당 정책을 보면, 그냥 deny이다..
재밌는 점은 istio-system 네임스페이스, 즉 전역으로 설정이 될 것처럼 생겼다는 것.
그리고 내가 설정한 이름으로 이름이 정해지지도 않았다.

이 정책이 진짜 어디 적용되는지는 각 워크로드를 들어가보면 알 수 있다.
정책은 제대로 reviews에만 적용된다.

test 네임스페이스의 요청은 바로 막혀버리는 것을 확인할 수 있다.

L4 Authorization Policy

이제 L4 레벨의 인가 정책을 설정해본다.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-review-debug
spec:
  selector:
    matchLabels:
      app: reviews
#  action: ALLOW
  action: DENY
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/default/sa/debug

기본 네임스페이스의 debug에서 들어오는 요청은 허용하지 않도록 설정해본다.

이번에도 해당 이름의 정책이 설정됐다.
이름과 설정 정보가 이상한? 건 Peer Authentication 쪽이라는 걸 확실하게 알 수 있는 대목.
해당 리소스의 설정을 적용할 때 ztunnel의 정책 양식으로 바꾸기 위해 istiod가 자체적으로 변형을 조금 가하는 것으로 보인다.

아무튼 확실하게 기본 네임스페이스의 debug에서만 요청이 거부된다.

L7 Authorization Policy

이제부터는 웨이포인트가 있어야만 적용될 수 있는 설정들을 넣어본다.
특정 http 헤더가 들어있으면 요청을 거부하도록 세팅해보자.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-with-header
spec:
#  selector:
#    matchLabels:
#      app: reviews
  targetRef:
    kind: Service
    name: reviews
  action: DENY
  rules:
    - when:
        - key: request.headers[deny]
          values:
            - "true"

deny란 헤더가 true로 설정되어 들어오면 해당 요청은 거부해본다.
주의할 점으로, L7 레벨의 정책을 적용할 때 이스티오에서는 반드시 targetRef를 통해 설정하도록 제한한다.[^21]
앰비언트 모드만을 위한 리소스가 아니다보니 이런 식으로 사용방법에 대한 제한이 생겼음에도 해당 부분에 대해 제대로 에러를 내뱉지 않는다..

그래서 이걸 설정하고 실제로 트래픽을 날려도 해당 요청은 성공한다.

  keti debug -- curl $ADDRESS -H "deny: true"

이제 웨이포인트를 사용해야할 순간이 왔다!

k label svc reviews istio.io/use-waypoint=waypoint

적용하는 것이 쉽고 빠르다는 것은 분명한 앰비언트의 장점인 것 같다.

보다시피 처음에는 무리 없이 성공했던 요청이 서비스에 라벨을 다는 것만으로 순식간에 적용됐다.

번외 - targetRef를 사용하지 않았을 때 디버깅

참고로 셀렉터를 이용해서 설정을 했을 때의 상황을 캡쳐했다.

잘못 세팅한 예시이나, 해당 부분에 대한 어떠한 경고도 주어지지 않는다.
그나마 이를 빠르게 판단할 수 있는 방법은 ztunnel에 설정이 들어갔는지 보는 것이라 생각한다.
웨이포인트와 ztunnel에 들어가는 설정은 명확하게 구분된다.
즉 웨이포인트에 들어가야 할 설정은 ztunnel에는 들어가서는 안 된다.

이렇게 설정 정보가 들어갔다면 설정을 잘못한 거니까 후딱 수정해주자.

트래픽 제어

마지막으로는 트래픽 제어를 해본다.
이 부분은 빠르게 하고 싶어서 그냥 문서의 예제를 가져다 썼다.[^22]

apiVersion: v1
kind: Service
metadata:
  name: reviews-v1
spec:
  ports:
    - port: 9080
      name: http
  selector:
    app: reviews
    version: v1
---
apiVersion: v1
kind: Service
metadata:
  name: reviews-v2
spec:
  ports:
    - port: 9080
      name: http
  selector:
    app: reviews
    version: v2
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: reviews
spec:
  parentRefs:
    - group: ""
      kind: Service
      name: reviews
      port: 9080
  rules:
    - backendRefs:
        - name: reviews-v1
          port: 9080
          weight: 90
        - name: reviews-v2
          port: 9080
          weight: 10

사전 작업으로 먼저 버전 별 서비스 리소스를 만들었다.
그 이후 리뷰로 들어가는 트래픽에 대해서는 각 서비스로 트래픽을 가중치에 기반해 보내도록 만드는 설정을 넣는다.

웨이포인트의 엔보이 라우트 설정을 뜯어보면 해당 설정이 적용된 것을 확인할 수 있다.

새로운 라우트가 추가되고 이 라우트는 트래픽을 분산하여 클러스터로 보낸다.

설정을 일일히 다시 뜯어보지는 않겠다.
다만 main_internal 리스너에서 구체적으로 해당 라우트로 트래픽을 보낼 수 있는 것은 main_internal에 설정된 filterChainMatcher를 통해 이뤄진다.

포트가 9080인 경우 inbound-vip|9080|http 필터로 요청을 수행하도록 설정된 것을 확인할 수 있다.

이제 100번 정도 요청을 때려보자!

for i in {1..100};
do
  keti debug -- curl $ADDRESS | jq '.podname'
done | sort | uniq -c

보다시피 90:10 정도로 트래픽이 제대로 분산된 것을 확인할 수 있다.

정책 적용이 되지 않는 케이스 - ztunnel에서 출발하지 않을 때

그러나 이 설정은 어디까지나 웨이포인트를 경유할 수 있는 트래픽에 대해서만 설정된다.
즉 ztunnel을 거치지 않는, 앰비언트 설정이 들어가지 않은 곳으로부터 트래픽이 날아가면 해당 설정은 무용지물이라는 것이다.

for i in {1..100};
do
  keti -n test debug -- curl $ADDRESS | jq '.podname'
done | sort | uniq -c

보다시피.. test 네임스페이스에서 보낸 요청은 해당 설정이 적용되지 않았다!

게이트웨이에서 보내는 요청 역시 마찬가지이다.

cat <<EOF | kaf -
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: test
spec:
  parentRefs:
  - name: bookinfo-gateway
  rules:
  - matches:
      - path:
          type: PathPrefix
          value: /reviews/1
    backendRefs:
      - name: reviews
        port: 9080
EOF

for i in {1..100};
do
  curl http://$GWLB/reviews/1 -s | jq '.podname'
done | sort | uniq -c

아예 게이트웨이에서 바로 reviews로 트래픽을 날릴 수 있도록 httproute를 추가했다.

이 트래픽 역시 ztunnel에서 날아가는 것이 아니므로, 웨이포인트의 트래픽 제어는 먹히지 않는다.

참고로 위 httproute는 정상적으로 설정이 적용된 상태이다.

결론

게이트웨이에서도 웨이포인트로 보낼 수 있게 하는 건 빨리 개발돼야 할 것 같다.
아니면 최소한 게이트웨이도 결국 엔보이인데, 웨이포인트 설정이 같이 적용되게 하던가.

관련 문서

지식 문서, EXPLAIN

기타 문서

참고